REPRODUCCIÓN Revisando las técnicas antianálisis de Play Ransomware

Resumen

El ransomware Play, también conocido como PlayCrypt, es un ransomware que apareció por primera vez en junio de 2022. El ransomware se ha dirigido a sectores como la sanidad y las telecomunicaciones, así como a un amplio abanico de regiones como Latinoamérica, Europa y Norteamérica. El ransomware Play es conocido por obtener acceso a las redes a través de cuentas válidas comprometidas o explotando vulnerabilidades específicas. Una vez dentro de la red, utiliza una gran cantidad de herramientas conocidas de post-explotación para continuar su ataque. Herramientas como Bloodhound, PsExec, Mimikatz y AdFind son algunos ejemplos de herramientas utilizadas anteriormente en ataques relacionados con este ransomware.

Otro aspecto del malware que lo hace famoso es la cantidad de técnicas antianálisis que utiliza en sus cargas útiles, como el abuso de SEH y el uso de ROP para redirigir el flujo de ejecución. Al emplear técnicas para ralentizar el proceso de ingeniería inversa, los actores de la amenaza dificultan la detección y prevención del malware. 

En 2022, otros investigadores publicaron una excelente entrada en su blog en la que analizaban el malware en sí y algunas de las técnicas antianálisis que utilizaba. En esta entrada del blog, revisaremos las técnicas antianálisis empleadas por variantes recientes del ransomware Play, explicando cómo funcionan y también cómo podemos derrotar algunas de ellas utilizando scripts de automatización.

Programación orientada al retorno (ROP)

Cuando se realiza ingeniería inversa de Malware, asegurarse de que el flujo de control no está ofuscado es una de las primeras cosas que tenemos que hacer para entender correctamente el Malware. 

Como intento de ofuscar su flujo de control, el ransomware Play utiliza a menudo una técnica ROP en su carga útil. Lo hace llamando a más de cien funciones que parchean el valor en la parte superior de la pila y, a continuación, redirige el flujo de ejecución a él. Antes de hablar de cómo lo hace exactamente el malware, echemos un vistazo a cómo funcionan en general las instrucciones de ensamblaje CALL y RET.

Cuando se produce una LLAMADA (una llamada cercana en este Caso para ser más específicos), el procesador empuja el valor del registro del puntero de instrucción (EIP en este Caso) en la pila y luego se bifurca a la dirección especificada por el operando objetivo de la llamada, que en este Caso es un desplazamiento relativo al puntero de instrucción. La dirección en el puntero de instrucción, más este desplazamiento, dará como resultado la dirección de la función a la que se va a llamar.

La instrucción RET, por otro lado, indica el final de una llamada de función. Esta instrucción es responsable de transferir el flujo de control del programa a la dirección en la parte superior de la pila. ¡Y sí, esta es exactamente la dirección inicialmente empujada por la instrucción de llamada!

Teniendo en cuenta lo mencionado, en un escenario ideal, la dirección resaltada en la imagen a continuación sería la siguiente instrucción que se ejecutará después de una llamada a la función objetivo (sub_42a4b9):

Lo que hace el malware para abusar del funcionamiento de las instrucciones CALL y RET puede observarse en la siguiente imagen:

Una vez que se llama a la función, la dirección 0x42a4b4 se envía a la pila, por lo que ESP apuntará a ella. A continuación, la función llamada añade el valor 0xA a la dirección apuntada por ESP y, a continuación, devuelve mediante la instrucción RET. Estas operaciones dan como resultado que el flujo de control se redirija a 0x42a4be (0x42a4b4 + 0xa) en lugar de 0x42a4b4.

Al aplicar esta técnica, el malware no sólo hace más complejo el análisis estático, ya que el flujo del programa no será trivial, sino que también puede dificultar la depuración, porque si se pasa por encima de este tipo de funciones pueden ocurrir muchas cosas antes de que se ejecute la "siguiente instrucción" normal.

Otra forma en que el malware implementa esta técnica ROP es utilizando el enfoque que se muestra en el código de abajo, que es muy común en los shellcodes. El desplazamiento especificado por el operando de destino de la instrucción de llamada es cero, lo que da como resultado que la dirección de la función a la que se llamará sea exactamente la dirección de la siguiente instrucción. A continuación, esta dirección se inserta en la parte superior de la pila y el resto de las operaciones son exactamente las mismas que en el ejemplo anterior:

Para ayudar en el análisis del ransomware Play, Netskope Threat Labs desarrolló un script, basado en el trabajo previo de otros investigadores, para arreglar la ofuscación ROP empleada.

El script busca posibles candidatos a ROP, recopila el desplazamiento que se agregará a la parte superior de la pila y parchea las direcciones que realizan las llamadas ROP con un salto absoluto, donde el objetivo es la dirección de transferencia modificada calculada en tiempo de ejecución.

A continuación se muestra un ejemplo del aspecto que tendría la carga útil del malware antes y después de la ejecución del script:

Antes:

Después:

Anti-desmontaje

Una técnica anti-desensamblado utilizada para engañar a los analistas y desensambladores es transferir el flujo de ejecución a objetivos ubicados en medio de otras instrucciones válidas.

Tomemos como ejemplo la llamada a la función en 0x42a4af utilizada en la sección ROP anterior. Los códigos de operación para esa instrucción CALL son "E8 05 00 00 00". El 0xE8 de bytes es el código de operación de la propia instrucción CALL y los otros 4 bytes representan el operando de destino (el desplazamiento relativo a EIP).

Como hemos comentado anteriormente, la dirección de la función a llamar sería el valor de EIP (0x42a4b4) + el offset (0x5) y eso da como resultado la dirección 0x42a4b9. Sin embargo, este valor cae en el último byte de otra instrucción válida en 0x42a4b5:

En términos de ejecución, este tipo de comportamiento no cambia nada porque el procesador entenderá las instrucciones correctamente. Sin embargo, es posible que un desensamblador no presente las instrucciones correctamente dependiendo del enfoque que utilice (p. ej. barrido lineal), lo que hace que el análisis estático sea un poco complicado.

El script que proporcionamos para corregir las llamadas de ROP también controla este escenario para los destinos de ROP. Teniendo en cuenta que usamos una instrucción JMP para parchear las llamadas, terminamos también obligando al desensamblador a comprender el flujo correcto a seguir.

Código basura

Aunque se trata de una técnica muy sencilla, merece la pena mencionarla porque puede ralentizar definitivamente el análisis del malware. La técnica de inserción de código basura/basura es exactamente lo que su nombre sugiere: la inserción de instrucciones innecesarias en el binario. 

A diferencia de las técnicas presentadas hasta ahora, la inserción de código basura no engañaría al desensamblador, pero podría hacerle perder tiempo analizando código innecesario y el ransomware Play lo utiliza con bastante frecuencia, especialmente en los objetivos de las llamadas ROP.

Manejo estructurado de excepciones (SEH)

Otra técnica antianálisis utilizada por el malware es abusar de un mecanismo de Windows llamado Structured Exception Handling que se utiliza para manejar excepciones.

En el sistema operativo Windows, cada subproceso tiene una estructura denominada Bloque de entorno de subprocesos (TEB). En un entorno x86, la dirección de TEB se encuentra en el registro FS y contiene información útil para el propio subproceso y reside en el espacio de direcciones del proceso. El primer campo de esta estructura es otra estructura llamada Thread Information Block (TIB) y el primer elemento de esta estructura contiene una lista de lo que se denomina "registros de registro de excepciones".

Cada uno de estos registros se compone de una estructura que contiene dos valores. El primero es un puntero al "siguiente" registro de la lista y el segundo es un puntero al controlador responsable de controlar la excepción.

En términos sencillos, cuando se produce una excepción, se llama al último registro agregado a la lista y decide si controlará la excepción desencadenada o no. Si ese no es el Caso se llama al siguiente manipulador de la lista y así sucesivamente hasta llegar al final de la lista. En ese Caso, se llama al manejador por defecto de Windows.

La forma en que Play abusa de esta característica es insertando su propio controlador de excepciones en la lista de control de excepciones y, a continuación, forzando una excepción. En el ejemplo siguiente, el registro EBX contiene la dirección del gestor de excepciones del Malware y, una vez insertado como primer elemento de la lista (las cuatro instrucciones resaltadas en la parte superior), el Malware pone a cero EAX y lo divide por cero, provocando una excepción (las dos instrucciones resaltadas en la parte inferior):

Una vez que se desencadena la excepción, se llama al último controlador registrado. El Malware utiliza este primer manejador para registrar y llamar a un segundo forzando una segunda excepción, pero ahora a través de la instrucción INT1 para generar una excepción de depuración. El segundo manejador registrado es el responsable de avanzar en la ejecución "normal" del Malware.

Esta técnica puede resultar muy molesta a la hora de depurar el malware, ya que el depurador detendría la ejecución cuando se produjera la excepción, obligándonos a encontrar el manejador de excepciones y asegurándonos de antemano de que tenemos control sobre él.

Ofuscación de cadenas

Todas las cadenas relevantes utilizadas por el malware están ofuscadas, lo que dificulta la señalización estática de cualquier cadena relevante. Para desofuscar sus cadenas en tiempo de ejecución, el malware genera una clave de 8 bytes y la utiliza como entrada para el algoritmo de desofuscación.

El algoritmo para generar la clave es bastante sencillo. Recibe un valor de inicialización codificado de forma rígida y realiza algunas operaciones aritméticas básicas dentro de un bucle. El contador de bucles también es un valor codificado de forma rígida que solía ser muy grande en las muestras analizadas (p. ej. 0x20c87548). 

Podemos simplificar las operaciones utilizadas para generar la clave en el siguiente fragmento de python:

x = semilla
y = 0
i = 0

Mientras < contraataque:
    a = (x * x) >> 32
    b = (x * y) + (x * y)
    Si Y:
        y = (a + b) & 0xffffffff
    más:
        y = a
    x = ((x * x) & 0xffffffff) + i
    i += 1

clave = struct.pack("<2I", *[x, y])

El algoritmo utilizado para desofuscar las cadenas implica algunos pasos más y algunas otras operaciones como AND, OR y NOT. Estas operaciones se aplican en la propia cadena ofuscada y el último paso del bucle de desofuscación es aplicar una operación XOR de varios bytes mediante la clave de 8 bytes generada anteriormente. Las operaciones se pueden simplificar en el siguiente fragmento de python:

i = 0

Mientras < len(enc_str):
    dec_str[i] = enc_str[i]
    j = 0
    Mientras que J < 8:
        v1 = (dec_str[i] >> j) y 1
        v2 = (dec_str[i] >> (j + 1)) y 1
        Si v1 != v2:
            Si v1 == 0:
                dec_str[i] = (dec_str[i] & ~(1 << (j + 1))) & 0xFF
            más:
                dec_str[i] = (dec_str[i] | (1 << (j + 1))) & 0xFF
            Si v2 == 0:
                dec_str[i] = (dec_str[i] & ~(1 << j)) & 0xFF
            más:
                dec_str[i] = (dec_str[i] | (1 << j)) & 0xFF
        j += 2

    dec_str[i] = ~dec_str[i] y 0xFF
    dec_str[i] = (dec_str[i] ^ clave[i % len(clave)]) & 0xFF
    i += 1

Vale la pena mencionar que los algoritmos contienen muchas operaciones basura que no son necesarias para la desofuscación en sí y que se eliminaron en los fragmentos presentados.

El equipo de Netskope Threat Labs creó dos scripts para ayudar en el proceso de desofuscación: uno para generar automáticamente la clave de 8 bytes y otro para realizar el descifrado de la cadena.

Hash de API

El malware utiliza la conocida técnica API Hashing para resolver las funciones de la API de Windows que utiliza en tiempo de ejecución. El algoritmo utilizado es el mismo que el marcado en 2022 que es xxHash32, con la misma semilla de 1 proporcionada a la función hash. 

El algoritmo xxHash32 puede ser fácilmente reconocido por la cantidad de constantes que utiliza en sus operaciones:

En un intento de ofuscar aún más las funciones hash, el malware añade o sustrae constantes específicas a los resultados hash. El valor constante es diferente para cada muestra. A continuación se muestra un ejemplo en el que el malware añadió el valor 0x4f5dcad4 al resultado hash:

Detección de Netskope

• Netskope Threat Protection
  • Win32.Ransomware.Playde
• Netskope Advanced Threat Protection proporciona una cobertura proactiva contra esta amenaza.
  • Gen.Malware.Detect.By.StHeur y Gen:Heur.Mint.Zard.55 indica una muestra detectada mediante análisis estático
  • Gen.Detect.By.NSCloudSandbox.tr indica una muestra que fue detectada por nuestro Sandbox en la nube

Conclusión

Como podemos observar en esta entrada del blog, el ransomware Play emplea múltiples técnicas anti-análisis como un intento de ralentizar su análisis. Desde la ofuscación de cadenas hasta el ROP y el uso del secuestro SEH, los actores de amenazas a menudo actualizan su arsenal y amplían sus técnicas para que el impacto de sus ataques sea aún más destructivo. Netskope Threat Labs continuará siguiendo la evolución del ransomware Play y su TTP.

Iocs

Todos los IOC relacionados con esta campaña, los scripts y las reglas de Yara se pueden encontrar en nuestro repositorio de GitHub.